home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / psion / forg.txt < prev    next >
Text File  |  1994-01-21  |  4KB  |  99 lines

  1. The following is a summarised version of comments made on CIX by Martin
  2. Budden, (Software Engineer at Psion).  I'm posting here with his
  3. agreement.
  4.  
  5. Cheers,
  6. Chris Hennings
  7.  
  8. ======================================================================
  9. I've just had a look at Artworks and it has prompted me to make a few
  10. general comments about writing OPL programs.
  11.  
  12. There are two types of files that a program can use: the files the
  13. program actually manipulates (I'll call these its data files) (eg
  14. the .DBF file used by the database), and the files the program needs
  15. to run (I'll call these its program files) (eg any bitmaps it needs to
  16. load, or any .OPOs that it loads using LOADM).  People seem to have
  17. adopted various solutions to the problem of where to put these files,
  18. I thought I'd offer some 'official' guidance.
  19.  
  20. The locations of an OPA's data files is determined by the PATH
  21. keyword in the APP ... ENDA structure.  Artworks has chosen
  22. \OPD\ARTW.  This is a reasonable choice, however we feel that if you
  23. consider your application reasonably serious then you are justified
  24. in creating your own directory off the root, so \ART, \ARTW, or
  25. \ARTWORKS would be equally good, if not preferable choices.  We tend
  26. to use 3 character directory names at Psion, but this is just house
  27. style.  Use your judgement, if you are writing a small utility OPA
  28. then it is better to use a directory off \OPD.
  29.  
  30. If your OPA creates any data files (besides the ones that are
  31. shown under the icon) then you should give the user some way of
  32. specifying which drive should be used for these files.  It is annoying
  33. to the user if they are always created on M:, since this uses memory
  34. that they may need for running applications (especially true if they
  35. have memory-hungary applications eg the Spreadsheet).
  36.  
  37. An OPA's program files should NOT be stored in the same place as its
  38. data files: THE USER SHOULD BE ABLE TO DELETE ALL THE FILES IN A
  39. PROGRAM'S DATA DIRECTORY AT ANY TIME.  So where should you put the
  40. program files?  In a directory of the same name as the OPA - this is
  41. the standard that we have adopted at Psion for any APPs that are
  42. released on SSDs (eg Chess).  An example will make this clearer.
  43. Artworks requires a number of .PIC files to run (eg its title screen),
  44. these should be placed in \APP\ARTWORKS, eg
  45.  
  46.     \APP\ARTWORKS\ARTTITLE.PIC
  47.     \APP\ARTWORKS\ARTWORKI.PIC
  48.  
  49. etc, since ARTWORKS.OPA itself resides in \APP\ARTWORKS.OPA.  How do
  50. you do this?  Again an example should make things clear:
  51.  
  52. PROC loadbt%:(name$)
  53.     LOCAL file$(128),off%(6)
  54.     file$ = PARSE$("",CMD$(1),off%())
  55.     file$ = LEFT$(file$,off%(5)-1) + "\" + name$
  56.     RETURN gLOADBIT(file$)
  57. ENDP
  58.  
  59. so loadbt%:("ARTTITLE.PIC") will eventually call
  60.  
  61.     gLOADBIT("LOC::A:\APP\ARTWORKS\ARTTITLE.PIC")
  62.  
  63. (presuming the pack containing Artworks is in drive A).
  64.  
  65. CMD$(1) is used to get the full path used to start running artworks,
  66. and PARSE$ is used to find the position of the .OPA extension which
  67. is then replaced with "\" + name$.
  68.  
  69. A similar approach should be used when loading .OPOs with LOADM, or
  70. indeed loading any type of file.
  71.  
  72. If the above approach is adopted then the user also has the
  73. flexibility of changing the OPA's (or OPO's) directory.  For example
  74. I have created a GAMES.ALS which runs any .OPOs in the \GAMES
  75. directory, I have placed Minesweeper in this directory.  So
  76. chennings, how about adopting the above convention for Minesweeper?
  77.  
  78. The above is written in the spirit of constructive criticism, I hope
  79. I have not given the impression that I am knocking Artworks (or
  80. Minesweeper).
  81.  
  82. ======================================================================
  83. If a program is a multi-file app (ie type 2 to type 4) then you have
  84. no choice, it must be distributed as an OPA, since there is no way of
  85. getting the file name onto the command line.
  86.  
  87. If a program is a 'no file' or 'one file' app (ie type 0 or type 1) then
  88. you have the choice OPO or OPA.  Actually you can cheat: distibute
  89. the program as an OPA.  This means the user can install it if they
  90. wish.  However they can also rename it to *.OPO and copy it to \OPO
  91. and it can then be launched from the OPL bubble.  So for instance you
  92. could make Mines an OPA and then the user could put it where they
  93. wished.
  94.  
  95. If programer's follow the PARSEing rules I outlined above then
  96. should be able to rename their OPAs and copy them to different
  97. directories with no ill effect.
  98.  
  99.